First CI round revealed two layered issues exposed by the new e2e:

1. **The shipped CDB carries ninja-escape artefacts.** `flags.cppm`'s
   `escape_path` ninja-escapes paths (`$ ` for space, `$:` for colon,
   `$$` for literal `$`) so they survive embedding in ninja rule strings.
   But the same escaped strings flow verbatim through `f.cxx` into
   `compile_commands.json`, whose `arguments` array is exec'd by clangd
   without any ninja involved. On Windows that makes `C:` appear as
   `C$:` in CDB → clangd can't resolve the path. POSIX usually escaped
   nothing in practice, hiding the bug; Windows drive letters always
   trigger `$:`.

   Fix in `compile_commands.cppm::split_flags`: same single pass now
   splits tokens *and* unescapes the three ninja sequences. Splitting
   was also broken for paths with a literal space (would've broken
   `-isystem "/path with space/include"` mid-arg) — that's fixed
   simultaneously since `$ ` is no longer a token separator.

2. **e2e test 47 needed Windows-friendly checks.** The original `[^"]+`
   grep returned the raw JSON-escaped form (`\\Users\\...`) and the
   `^[A-Za-z]:` regex didn't match `C$:`. Rewrote using `jq -r` (which
   does JSON un-escape natively, preinstalled on all GHA runners) and:
   - explicit ninja-escape sniff (`$:`, `$ `, `$$`)
   - both POSIX and Windows-drive absolute-path checks
   - basename check normalised against `\` / `/`

Net: CDB now contains plain paths in both runtimes, and the test fails
loudly if either layer regresses.

The Windows CI run reported:
  FAIL: basename is not pcm.cache/gcm.cache: 'pcm.cache
  '
The closing quote on the next line is the giveaway — the value carries a
trailing `\r`. `jq.exe` on git-bash emits CRLF; `mapfile -t` strips LF
but leaves CR, so every downstream comparison saw `pcm.cache$'\r'` and
failed. Trim with `${v%$'\r'}` per element.

The source-code fix (un-escape ninja sequences) is working — the value
itself is now a clean `C:\Users\...\pcm.cache`, no `$:` artefact.

Apple ships GPLv2-era bash 3.2 on macOS, which has no `mapfile` /
`readarray`. The previous round failed on ci-macos with:
  line 31: mapfile: command not found
  FAIL: 47_cdb_prebuilt_module_path_abs.sh (exit 127)

Replace `mapfile -t vals < <(jq …)` with `jq … > tmp.txt` followed by a
`while … read … done < tmp.txt`. Using input redirection (not a `|`
pipeline) keeps the loop in the current shell so `fail=1` propagates;
the temp file lives under $TMP and is cleaned up by the script's trap.

Empty-list signal now uses `[[ ! -s "$TMP/vals.txt" ]]` instead of array
length — same semantics, no bashism.